The jinit.tcl library is distributed as part of the jstools package. It consists of a procedure, j:jstools_init, that reads user preferences and initialises data used by the jstools libraries. Any application that uses the jstools libraries should either call j:jstools_init early on, or duplicate its functionality.
This document describes jinit.tcl version 3.6/3.0.
Usage
Accessing the Library
In order to use the jinit.tcl library, it (and any other libraries it depends on) must be in your Tcl auto_path, described in tclvars(n). Information about how to arrange that, and other conventions common to the jstools libraries, is in the Usage section of The jstools Libraries.
Credits and Copyright
Author
Jay Sekora
js@bu.edu
http://shore.net/~js/
Copyright
The library is copyright ⌐ 1992-1994 by Jay Sekora, but may be freely copied and modified for non¡commercial purposes. (Please contact me if you want to use it for a commercial purpose, this may be OK under some circumstances.)
Overview
Procedure
j:jstools_init - common initialisation for jstools applications and libraries
j:jstools_init
Usage
j:jstools_init
Description
This procedure performs common setup tasks for the jstools applications and other applications using the jstools libraries. Specifically, it does the following:
* It sets the Tk colormodel to colour if possible (even on displays with only a few colours). The Tk default is to use monochrome if the display supports sixteen colours or fewer, but many displays with as few as four colours have no trouble displaying Tk's 3¡D effects, so the jstools applications use colour if possible.
* It sets NAME and HOME global variables with the values of the corresponding environment variables.
* It sets the application's `client' and `command' properties for the use of X session managers.
* It reads in the user's global preferences. This is important, as many of the jstools libraries depend on the existence of variables created during this process.
* It sets up Text and Entry bindings to use the user's preferred editor emulation, and reads the user's ~/.tk/textbindings.tcl and ~/.tk/entrybindings.tcl, if any.
If you don't want to use j:jstools_init because there's something it does that you don't like, you should refer to the procedure itself to see what you need to do to initialise your application.
Evolution
Feel free to report bugs (and feature requests) to me, <js@bu.edu>, and I will try to deal with them. Also, feel free to fix bugs or add features on your own and let me know how you did it.
Bugs and Limitations
* Some applications may not use text widgets, entry widgets, or both. Initialising text and entry mappings is a waste of time and I/O in that case. (On the other hand, any application which uses such jstools procedures as j:fs or j:prompt_tcl needs entry bindings, and an application which uses j:more might need text bindings.)
* While colour works well for displays with small numbers of shades of grey, it may not work well for all displays with small numbers of actual distinct hues. Ideally, whether to use colour or monochrome would be decided based on the kind of display (e.g. StaticGray vs. DirectColor) as well as on the number of colours, or perhaps it would be a user preference.
* It would be nice if j:jstools_init could handle setting up the auto_path variable to find the libraries. Since it is itself called using the auto¡loading mechanism, of course, it can't.
